Repository navigation
Upgrade restate-sdk-shared-core to 8.4.0 - #305
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
ℹ️ No code issues. Two things to note before this ships: the state format becomes one-way, and some docs are now out of date.
Reviewed changes
I reviewed the restate-sdk-shared-core bump against the published 8.3.1 and 8.4.0 crates.
- Dependency bump:
Cargo.tomlnow asks for8.4.0with the same features. TheCargo.lockchecksum matches the crates.io tarball. 8.4.0's[dependencies]are the same as 8.3.1's, so no other lockfile entries change.
ℹ️ docs/agents/access-patterns.md describes 8.3.1's reader behavior
The doc says readers never reuse the process's cached state, so every view call fetches the head, the manifest and each tail entry again. With 8.4.0 that stops being true. A reader opened with .cached(...), as src/sessions.rs does, now reads through the PageCache. The new src/state/mod.rs says that "a steady-state open, an owner's or a reader's, and a flush are each one round trip". The measurements were taken at specific commits, so they still hold for those commits. The explanation and the "What to change next" item now point at a limitation upstream has removed.
Technical details
# access-patterns.md: reader cache claims are stale after shared-core 8.4.0
## Affected sites
- docs/agents/access-patterns.md:184-187 — "readers never use the process's state of the namespace (`src/state/mod.rs` in sdk-shared-core skips the cache for them)"
- docs/agents/access-patterns.md:277-279 — "the view pays it on every call, as readers never reuse the process's state"
## Required outcome
- Either scope these statements to 8.3.1 explicitly, or update them to say that from 8.4.0 on, warm reader opens go through the `PageCache` (only the head is uncached). Ideally, re-measure the warm `messages` view with `scripts/access_patterns.py`.claude-opus-5-5 ｜ 𝕏
| # The feature `sql` is the sessions' storage: the SQLite-compatible database kept in an | ||
| # object's state, with its page cache (foyer); `tunnel` is Restate Cloud's. | ||
| restate-sdk-shared-core = { version = "8.3.1", features = [ | ||
| restate-sdk-shared-core = { version = "8.4.0", features = [ |
There was a problem hiding this comment.
8.4.0 changes the format of the sessions' state, and the change only works in one direction. Every flush now writes an SH23 head with tail keys named by nonce (v22/tail/<version>-<nonce>/<part>). 8.4.0 still reads the old SH22 heads, but 8.3.1's Head::decode accepts only SH22 and fails with invalid("head"). v1.4.2 already ships sql sessions on 8.3.1. So once a release with this bump flushes a session key, rolling back to ≤1.4.2, or an old deployment still serving that key, can no longer open it. The PR description says nothing about this, and the release notes should say it.
There was a problem hiding this comment.
Correct: this was decided in sdk-shared-core#113 ("Older SDKs can't read SH23 heads; no compatibility release at this point"), so this PR can't add a path back. I've added it to the PR description, so it can go into the release notes.
Generated by Claude Code
|
On the ℹ️ note about Generated by Claude Code |
Bumps
restate-sdk-shared-corefrom 8.3.1 to 8.4.0. The release brings the plain read-through cache for the sessions' state, with unique tail entry names (#113). The features stay the same.Only
Cargo.tomlandCargo.lockchange, and no code has to change.For the release notes, the sessions' state format only goes forward. Every flush in 8.4.0 writes an
SH23head, and 8.4.0 still reads theSH22heads that ≤1.4.2 wrote. 1.4.2 (shared core 8.3.1) can't read anSH23head, though. So once a release with this bump has flushed a key's state, rolling back to ≤1.4.2, or an old deployment still serving that key, can't open it. As sdk-shared-core#113 says, there's no compatibility release.Locally:
cargo buildis clean andjust test-fastgives 352 passed.🤖 Generated with Claude Code